Do not propagate_to_hidden RouteFocusChanged events #2416
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This fixes a bug I've been having when trying to update https://github.com/smmalis37/sudoku_rust from Druid v0.7 to v0.8. To reproduce the bug:
On my system this results in bizarrely inconsistent behavior, where some boxes will accept text input, but other boxes won't, seemingly randomly. I've done a bunch of debugging and this PR is my conclusion.
The root of the problem seems to be that BuildFocusChain isn't routed to hidden widgets but RouteFocusChanged is. When combining this with an Either, I seem to get into a state where every RouteFocusChanged event gets routed to both sides of the Either, resulting in merge_up seeing the hidden child having child_state.update_focus_chain be true, which leads to a BuildFocusChain event getting sent, which doesn't go to the hidden side, meaning that side's update_focus_chain never gets cleared. This means we're rebuilding the focus chain in the middle of handling every focus change, which I imagine can cause weirdness and doesn't feel right to me.
Some spot checking of other areas in the code also makes me feel that this is the right thing to be doing. For example RouteDisabledChanged already handles resigning focus if it previously had it, so RouteFocusChanged still going to a newly disabled widget shouldn't be necessary I think.